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Abstract 

With the increasing growth of electronic communica- 
tions, it is becoming important to provide a meclianism for 
enforcing various security policies on network communi- 
cations. This paper discusses our implementation of sev- 
eral previously proposed protocols that enforce the Bell La- 
Parfula security model. We also introduce a new protocol 
called "Quantized Pump" tlxat offers several advantages, 
and present experimental results to support our claims. 



1 Introduction 

This paper examines the measured covert channel rate in 
various proposed methods for enforcing the Bell-LaPadula 
security model [i] in networks with two sensitivity levels: 
high arid low. Comparative results derived using TCP over a 
lOMb/s ethernet are presented. Our studies were concerned 
with four parameters: 

• Overall throughput — how much data can be sent 
from the low security side to the high security side 
per unit of time; 

• Covert channel throughput — how much data can a 
malicious process on the high security side send to 
the low security side per unit of time; 

• Space utilization — how much buffer space is re- 
quired to adequately control the covert channel; 

• Reliability — does the communication preserve the 
transport protocol reliability? 

Starting with the simplest and most straightforward pro- 
tocols, we discuss the basic problems and pitfalls of enforc- 
ing one-directional data flow in section 2. We also examine 
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why covert timing channels are inherent in reliable commu- 
nications. 

In sections 3, 4, and 5, we move on to more complex 
protocols: SAFP (Store and Forward Protocol), the Pump, 
and the Upwards Channel. We discuss their distinct fea- 
tures and measure some covert channel utilizations. We 
then discuss our implementation of these protocols, men- 
tion various implementation pitfalls to avoid, and compare 
the experimental performance of these protocols. 

In section 6, we introduce a new protocol called "Quan- 
tized Pump" that offers several advantages. Its design goals 
were to make it easy to analyze and easy to control. Covert 
channel bandwidth can be set precisely to any value desired. 
We present three different versions of the Quantized Pump 
that have different throughput/space tradeoffs. We discuss 
our implementation of all three versions and the results of 
our experimental measurements of the protocols. 

The following table shows a brief summary of features 
of various protocols we discuss in this paper: 



Protocol 


C Chan. 


Bound 


Rel. 


Thrpt 


Buffer 


SAFP 


Yes 


No 


Yes 


1.0 




Pump 


Yes 


No 


Yes 


0.9 




Up. Channel 


No 


Yes 


No 






Q. Pump 


Yes 


Yes 


Yes 


1.0 


N* 


Log. Q. Pump 


Yes 


Yes 


Yes 


0.9 


N log N 


Lin. Q. Pump 


Yes 


Yes 


Yes 


0.4 


N 



Table 1: Protocol Summary 



The Covert Channel (C. Chan.) column shows whether 
or not a protocol allows covert channels. The Bound column 
refers to whether or not it is possible to set the covert channel 
bandwidth to an exact value. The Reliability column indi- 
cates whether or not communication channel provided by a 
protocol is reliable. The Throughput column lists relative 
throughputs, expressed as a fraction of SAFP's throughput. 
The Buffer Size column describes the space complexity of 
the protocols with respect to the maximum rale at which the 
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sender on the low security network can send data. The " — 
" are present in the entries where the respective parameter 
is a manually preset constant and cannot be meaningfully 
compared to the other entries in the table. 

2 Simple Solutions 

There are several simple ways to enforce the Bell- 
LaPadula security policy for high-low communications net- 
works connected at a gateway. In this section we discuss 
some of these methods and also discuss the reasons why 
they are inadequate for most general scenarios. (Note that 
we want to be able to do this without modifying any pro- 
grams on the sender side or on the receiver side. We do not 
trust either the sender or the receiver; after all, that is why 
we are concerned with enforcing the security policy in the 
first place.) 

2.1 ACK Filter 

Another solution is to connect a low security network 
to a high security network with a special gateway called 
"ACK Filter." This gateway forwards any data from the 
low security network to the high security network, but only 
forwards acknowledgments of data receipt (which are nec- 
essary for reliable communication) from the high to the low 
network. This seemingly solves the problem of protecting 
highly sensitive data in the high security network, since the 
data cannot actuality be sent to the low security network — 
only the acknowledgments — but there is a problem: covert 
channels. 

An intruder on the high security network can use the times 
of acknowledgments to signal the low security network. 
For instance, the intruder might acknowledge some packets 
immediately and use that as a code for 0, and acknowledge 
other packets after half a second delay and use that as a code 
for 1. This is known as a covert timing channel, since it is 
the time that is used to convey unauthorized information. 

Description and analysis of covert channels in commu- 
nications protocols can be found in [2, 3, 4, 5]. 

Data acknowledgments are necessary to insure reliable 
communication and yet they introduce a Covert channel. 
There is a conflict between security and reliability. Fortu- 
nately, there are ways to minimize such covert channels. 

2.2 Blind Write-Up 

We can sacrifice reliability and use the blind write-up 
method, i.e. eliminate acknowledgments and hope that all 
data gets through. This eliminates the covert channel, but 
some data might be lost due to congestion, data may be sent 
to a machine that is down, the receiving machine may not 



be fast enough to process the data, etc., so this method is not 
usually acceptable. 

This approach can be improved by introducing a buffer 
to enhance reliability. This protocol is called the "Upwards 
Channel" or "One- Way Forwarder" and is discussed in sec- 
tion 5. 

3 Store and Forward Protocol (SAFP) 

The Store and Forward Protocol is the simplest conven- 
tional protocol for reliable communication across two net- 
works. Its usefulness for eliminating covert channels is 
limited at best; we mention it here because it is a benchmark 
against which to compare the performance of more complex 
protocols. 
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Figure 1: SAFP 

The idea of this protocol is simple: there is a gateway 
between a low security network and a high security network. 
When the gateway receives a packet from the low side, it 
stores the packet in a buffer and sends an acknowledgment 
back to the low side. The gateway transmits the packet to 
the high side and waits for an acknowledgment. When it 
gets the acknowledgment, it deletes the message from the 
buffer. If the gateway doesn't receive the acknowledgment 
or receives a negative acknowledgment, 1 it can retransmit 
the message. Except for acknowledgments, all data from 
the high security network is ignored; nothing is forwarded 
to the low security network. (Fig. 1) 

3.1 The Covert Channel 

The covert channel appears when the SAFP buffer fills 
up. This will happen if the high side processes messages 
slower than the low side is sending them. When the buffer is 
full, SAFP cannot move messages from the network device 
to the message buffer immediately upon receiving them, and 
must wait for buffer space to become available before it can 
store the message and send an acknowledgment to the low 
side. In other words, the time it takes to free the buffer space 
(i.e. the time it takes to receive an acknowledgment from 
High) is directly related to the time it takes SAFP to send 
an acknowledgment to Low. Thus the high side can control 



1 TCP does not use NACKs. 
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the rate of acknowledgments to Low by keeping the buffer 
full and varying the time of its acknowledgments. 

Fig. 2 plots acknowledgment number versus the time 
it takes to get that acknowledgment as seen from the point 
of view of the sender on the low security network. This 
illustration has no covert channel and hence all of the times 
are uniformly and randomly distributed near zero. 

Horizontal axis: At the time the transfer begins, a con- 
ceptual ACK counter is set to 0; it is incremented for each 
ACK sent to the lower sender. Vertical axis: The time be- 
tween successive ACKs, as received by the sender on the 
low security network. 
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Figure 2: SAFP, no covert channel 

Fig. 3 shows the same communication but with a covert 
channel present In this case, High is trying to send alter- 
nating zeros and ones to Low, encoded by "no delay" for 0 
and "500 ms delay" for 1. This illustration was produced by 
nmfttng S AFP over TCP Reno. 
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Figure 3: SAFP, covert channel present 

The covert channel in SAFP was substantially analyzed 
in [7], section 3.L We approached the analysis of this 
channel from the alternative perspective of average traffic 
analysis, and we were able to get experimental numbers for 
the bandwidth of the covert channel. 

Assume the simplest possible situation, where High is 



trying to signal Low by using long acknowledgment delays 
for 1 and no delay for 0. For simplicity, further assume 
that it takes twice as much time to send a 1 as it takes to 
send a 0. (This ratio of 2: 1 was found in our experiments to 
be the smallest ratio where Is are still reliably detectable.) 
Since the "cost" (time) to send a 1 is different from the cost 
of sending a 0, the optimal encoding no longer consists of 
50/50 ratio ofOs to Is. 

We can find this optimal ratio as follows: let the cost of 
sending a 0 be C and the cost of sending a 1 be 2C; also, 
let the probability of a 0 be p and the probability of a 1 be 
q — I -p. The average information transmitted per symbol 
is -(plogp 4- glogg). The average cost per transmitted 
symbol is Cp + 2Cq> so the amount of information trans- 
mitted per unit time is / = ~ (p £ *^° g <?? . The maximum 
of this expression is found at p =61.8%. (There are other 
ways of deriving this result, see [2].) 

From experimental results obtained by running SAFP 
over TCP Reno, we found that the error per acknowledgment 
of transmitting a 0 is very low: less than 1%, whereas the 
error in transmitting a 1 is very high: close to 75%. (i.e. only 
one of every four acknowledgments was carrying sufficient 
tuning information to identify it as a code for 1). This is 
caused by several factors; one of the most important is the 
influence of the TCP sliding window. (See Section 3.2.3 for 
further details on the TCP window.) 

Now we can find the exact maximum bandwidth of the 
covert channel by using the standard formula for binary in- 
formation transfer in noisy channels (see [8], section 4.2): 

H x v) = Ex E y P( x v) log p fi)7(i) > where x refers t0 ls 
and y refers to 0s. Applying this formula to our previous 
results, we get that the information content of an acknowl- 
edgment from the high side is approximately 0.1 bits, i.e. it 
takes about 10 acknowledgments to send 1 bit of data. The 
optimal encoding requires 61% 0s and 39% ls, so if C is the 
time to send a 0, then it would take 6C+ 4 x2C = HCtime 
units to send a single bit of data (on average). The average 
transmission rate in our experiments was about 3 millisec- 
onds/acknowledgment (see Table 3 and section 3.3 for more 
details), so the time to send a single bit was: 3 x 14 = 42 
milliseconds, which implies the covert channel bandwidth 
of approximately 24 bits/second. 2 

This is a fairly high bandwidth covert channel but it might 
be acceptable in some situations. The virtue of SAFP is that 
it is simple to implement and easy to analyze. The drawback 
is that it allows a high bandwidth covert channel. 

3.2 Implementation 

The Store and Forward Protocol was implemented as an 
xkernel protocol [10] above TCP. The SAFP protocol is an 

2 We should point out that this capacity is for a 0- 1 single bit encoding 
only. Other encodings might yield higher covert channel band widths. 
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application layer protocol using two separate TCP/IP stacks. 
Fig. 4 demonstrates the protocol stack used on the gateway. 
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Figure 4: SAFP gateway protocol stack 



3.2.1 TCP Gateway 

Both TCP and IP protocols were modified to play the role 
of a gateway. The main modification was to make both of 
them direct all packets up the stack of protocols to SAFP, 
even if the IP address does not match the IP address of the 
gateway machine and even if TCP does not know of the port 
being connected to. They were also modified to "spoof" 
IP addresses and TCP port numbers. In essence, SAFP is 
pretending to be High to Low and pretending to be Low 
to High. This provides a clean and completely transparent 
paradigm for both High and Low. Neither High nor Low is 
aware that there is a gateway between tbem. 

3.2.2 Reliable Open 

Performing a reliable open is a problem with this spoofing 
of IP addresses and TCP ports. When Low opens a connec- 
tion to High, the gateway running SAFP will intercept the 
message, and establish the connection with Low while mas- 
querading as High. Then it will connect to High, pretending 
to be Low. The problem is in doing this reliably. 

Since SAFP is running above TCP, by the time SAFP 
is notified about an incoming connection, TCP has already 
established the connection with Low. Moreover, Low's 
TCP can send data to the gateway immediately afterwards 
and before SAFP has anything to say about it. Now suppose 
that when SAFP tries to connect to High, the connection is 
refused. By this time Low may have already sent some data 
to SAFP, because SAFP already established a connection 
with Low, and that data already had been acknowledged by 
the gateway's TCP. Reliability is lost because the data that 
was acknowledged will never be delivered to High. 

There is not much that can be done about this problem 
as long as SAFP is running above TCP. It is possible to 



prevent Low from sending any data until SAFP establishes 
a connection to High by setting the size of the TCP receive 
buffer to zero, but even the fact that the connection has 
been established is already a violation of a reliability issue. 
Because it is impossible to achieve a completely reliable 
open without running at TCP level, we chose to use the 
drawback to our advantage and speed up data transfers by 
accepting the data from Low at the highest possible rate 
while the connection to High is being opened. By the time 
SAFP finally establishes the connection to High, Low may 
have already sent many kilobytes of data to SAFP. For a 
small data transfer, Low may be finished before High is 
ready to receive any data; then SAFP turns into the Big 
Buffer scheme of [ 14]. 

3.2.3 Effects of the TCP Sliding Window 

TCP's sliding window is useful for combating covert chan- 
nels. The sliding window allows the sender to send several 
packets in a row, without waiting for acknowledgments, 
until the window is filled up. Likewise, the receiver can 
acknowledge several packets at once. 

The window helps to add timing noise to the covert chan- 
nels in the following way. When the sender sends several 
packets back-to- back and the receiver acknowledges them 
all with one ACK, we have only one piece of useful timing 
information for several packets. For every group of pack- 
ets sent, only one will get an acknowledgment that carries 
useful timing information. This is conceptually the same 
as timing noise. Hence, with a standard TCP window we 
were able to get the figure of about 75% timing noise in our 
tests, i.e on average only 1 out of every 4 packets got an ac- 
knowledgment with useful timing information. (This result 
will vary with the network environment and the details of 
the TCP implementation.) A direct corollary of the obser- 
vation is that by increasing the size of the TCP window — 
applications have full control over the size of receive buffer 
within TCP — we may increase the amount of noise on 
the covert channel, which in turn will decrease the amount 
of information that can be sent over the covert channel per 
packet of data 

3.2.4 Gateway Performance 

If the SAFP protocol is running on a workstation instead 
of a dedicated gateway, the workstation has to be at least 
twice as fast as the sending and the receiving workstations 
to guarantee optimal performance. SAFP has to do roughly 
twice as much work as either the sender or the receiver in 
the same time period: SAFP has to receive the data from 
one network and simultaneously send the data to the other 
network, thus employing two TCP/IP stacks at once, while 
both the sender and the receiver each use just one TCP/IP 
stack at the same time. 
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3.3 Experimental Results 



Our experimental tests were run on Intel 80486 proces- 
sors with 66Mhz clock speed running Mach operating sys- 
tem version 3.0 [9]. The protocols were running in the 
xkernel environment version 3.2 [10]. The xkemel pro- 
cesses which contained the gateway protocols were running 
at a high priority level. The sender and receiver protocols 
were running on identical machines with an identical setup 
as the gateway. 



Data Transferred 


360 KB 


720 KB 


1.4 MB 


Transfer Time 


37 s 


71 s 


152 s 


Transfer Rate 


9.7 KB/s 


10.1 KB/s 


9.2 KB/s 


Buffer Size 


100 KB 


100 KB 


100 KB 


Average Packet Size 


1382 bytes 


\m bytes 


1477 bytes 


Average Delay 


25ms 


28 ms 


31ms 



Table 2: SAFP, covert channel attack present 

Table 2 summarizes the performance of SAFP with a 
covert channel present. The covert channel was created by 
sending a random set of bits. It used a 250 millisecond 
delay on an ACK to signal a 1 and no delay to signal a 0. 
Such a long delay was chosen to make the behavior of the 
protocols with a covert channel more pronounced and easier 
to analyze. As a point of reference, the minimum useful 
delay for covert channel transmissions seemed to be around 
25-50 milliseconds. 

The data rates are quite low — only about 10 Kilo- 
bytes/second. Such low rates are due to several factors: 
a fairly slow processor, inefficiencies caused by running the 
protocols on Mach OS as a user process, and the fact that 
a covert channel is present. We do not consider such slow 
data rates to be a big drawback in our experiments, since 
all the rest of the protocols we implemented and examined 
were running in exactly the same environment and thus we 
can still effectively compare their performance. 

The TCP send and receive buffers were the standard 4K 
buffers. The test application was giving TCP a continuous 
stream of data blocks, each 1024 bytes long. By comparison, 
the average packet size of actual TCP packets that were 
going onto the wire was larger, as shown on the table, due to 
TCP repackaging. Still, the ratio of the TCP buffer sizes to 
the size of the packets was nearly 3:1, which means that the 
arguments of the previous section about the influence of the 
TCP window on the covert channel bandwidth fully apply 
here. 

The next table, Table 3, presents the summary of SAFP 
behavior without a covert channel. The covert channel intro- 
duced a factor of 3 slowdown into the channel as compared 
to Table 2. We were unable to get much above the rate of 
30K/s for data transfer in our experiments. 



Data Transferred 


360 KB 


Transfer Time 


12 s 


Transfer Rate 


30 KB/s 


Buffer Size 


100 KB 


Average Packet Size 


1334 bytes 


Average Delay 


3 ms 



Table 3: SAFP, no covert channel attack 

Finally, Table 4 provides a basis for comparison of gate- 
way protocols to direct communication between the sender 
and receiver with no gateway in between. Our SAFP pro- 
tocol was 6 times slower than optimal without any covert 
channels but only 1.3 times slower than optimal with the 
covert channel present. This shows that in our tests when a 
covert channel is present, much of the slowdown is due to 
artificial delays involved in creating a covert timing channel 
and not necessarily to the gateway software. 





No Covert Channel 


Covert Channel Present 


Transfer Time 


2s 


29 s 


Transfer Rate 


180 KB/s 


12 KB/s 


Data Transferred 


360 KB 


360 KB 



Table 4: No gateway between sender and receiver 

Using native Mach OS TCP in place of the xkernel TCP 
gave virtually identical performance. 

4 The Pump 

The Pump protocol (M. Kang and I. Moskowitz [7, 11, 
12]) substantially reduces covert channel bandwidth from 
that of SAFP. 

The idea is to improve the throughput and reduce the 
covert cannel bandwidth by using a historic average of 
High's rate of acknowledgments as the rate of sending ac- 
knowledgments to Low. The Pump consists of three parts: 
trusted low process, trusted high process, and the commu- 
nication buffer (Fig. 5). 




Figure 5: Pump 
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When the trusted low process receives a message from 
Low it will insert the message into the buffer, consult the 
current value of the moving average of the last m acknowl- 
edgment times from High, modify it somewhat using a prob- 
abilistic function for timing noise, then acknowledge the 
packet after waiting for that amount of time. By doing this, 
the trusted low process forces the low side to send messages 
at the rate that the high side can receive and process them 
but it does that indirectly and with random noise. 

The trusted high process of the Pump simply sends mes- 
sages from the buffer to the high side and computes the 
moving average based on the acknowledgment times. 

4.1 Covert Channel 

The Pump has a lower covert channel bandwidth than 
SAFR The moving average increases the number of pack- 
ets required for Low to detect that High has changed his 
acknowledgment delay. Introducing randomness into the 
delays also makes the detection of a rate change harder. 

The Pump does have covert channels. Fig. 6 illustrates 
one such channel. The communication is exactly the same 
as illustrated on Fig. 3 for SAFP but now we have the Pump 
protocol in place of SAFP. Here, the size of the moving 
average was chosen to be deliberately low (30 packets) as 
compared to the number of packets per covert bit (approx- 
imately 100 packets), thus allowing a big and pronounced 
covert channel, in order to better illustrate its appearance. 
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Acknowledgment Count 

Figure 6: Pump, covert channel attack present 

What is the covert channel bandwidth of the Pump? Kang 
and Moskowitz [7] have analyzed three possible exploita- 
tion strategies in terms of dependency on two variables:' the 
number of packets in the moving average and the size of 
the buffer. This does not say much about the total covert 
channel bandwidth possible with the Pump, since it is en- 
tirely possible that other strategies might be found or various 
combinations of these strategies might yield higher covert 
channel bandwidths. 

There is a substantial amount of information flowing from 



the high trusted process to the low trusted process on every 
packet. It consists of two pieces: 

• Buffer full/not full — this is necessary to make com- 
munication reliable; 

• The moving average — an n bit quantity of informa- 
tion passed from the high trusted process to the low 
trusted process on every packet. 

The average acknowledgment delay is ultimately con- 
trolled by the behavior of the high security network, and 
an obscured version of the quantity filters down to the low 
security network with every acknowledgment. This viola- 
tion of the Bell-LaPadula model is diminished because High 
cannot arbitrarily change this multi-bit value and has to fol- 
low certain rules in changing it, but several bits of data flow 
from High to Low on every packet. The random delays 
reduce the amount of information flowing down. 

The number of bits in the moving average implies an 
upper bound on the bandwidth of the covert channel, but 
it is too high to be of any use. The true bound is hard to 
calculate because the channel is continuous with a gradual, 
limited change behavior. The authors of the Pump protocol 
considered several specific attacks, and concluded that the 
covert channel bandwidth can be adequately controlled for 
those attacks by setting the size of the buffer and the number 
of packets used to compute the moving average. 

In section 6, we propose a new protocol based on the 
Pump which is easily analyzable, and has an easily con- 
trolled and provable maximum covert channel bandwidth. 

42 Implementation 

The Pump was implemented as an application layer pro- 
tocol over TCP in the xkernel environment. The original 
Pump was described as having the trusted high process and 
the trusted low process as separate entities and we talked 
about them as such in the preceding section. Logically they 
are a part of the same protocol, so in our implementation 
we made them into two separate threads instead of sepa- 
rate processes. Communication between the trusted high 
process (thread) and the trusted low process (thread) is ac- 
complished by a shared variable which conveys the value 
of the moving average from the trusted high process to the 
trusted low process. 

Fig. 7 illustrates the protocol stack used for the pump. 
As before, the Pump is an application layer protocol over 
two complete TCP/IP stacks. (For other implementations of 
the Pump protocol see [6].) 
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Figure 7: Pump gateway protocol stack 

The Pump runs above TCP. Both TCP and IP protocols 
were modified as with SAFP. Since TCP automatically ac- 
knowledges all packets that it receives before it forwards 
them up to the application layer, the Pump has to rely on 
setting the size of the receive buffer for flow control, i.e. 
opening the TCP window instead of explicitly sending an 
acknowledgment to Low. 

The original protocol described in [7] does not deal with 
the fact that the Pump may run over a sliding window pro- 
tocol such as ICR As we pointed out in our discussion of 
SAFP 3 the sliding window may introduce additional timing 
noise into the covert channel and is thus a useful artifact that 
should not be neglected. 

TCP's sliding window is denominated in bytes rather 
than messages. Extra care needs to be taken in opening the 
window in order to avoid introducing a new covert chan- 
nel. The window should be opened either by some fixed 
constant number of bytes or by the number of bytes of the 
last message, not by the number of bytes that High just ac- 
knowledged. Otherwise a new covert channel of up to 16 
bits per packet is introduced. 

4.3 Experimental Results 

Tables 4, 5, and 6 summarize behavior of our implemen- 
tation of the Pump with various parameters varying. In all 
three cases there is a covert channel attack present. As with 
SAFP, 1 was encoded with a 250 millisecond delay and 0 
was encoded with no delay. 



Data Transferred 


360 KB 


720 KJB 


1.4 MB 


Transfer Time 


41s 


78 s 


173 s 


Transfer Rate 


8.8 KB/s 


9.2 KB/s 


8.1 KB/s 


Buffer Size 


100 KB 


100 KB 


100 KB 


Moving Average 


60 packets 


60 packets 


60 packets 


Average Packet Size 


1362 bytes 


1373 bytes 


1379 bytes 


Average Delay 


23 ms 


30 ms 


31 ms 



Table 5: Pump, covert channel attack present 

Comparing Table 2 to Table 5, we see that the Pump's 



throughput is lower than SAFP by 10% to 12%. It is also 
1.4 times as slow as the no-gaieway throughput. This is 
probably an acceptable slowdown, since the Pump has a 
much lower covert channel bandwidth than SAFE 



Moving Average 


60 packets 


120 packets 


240 packets 


Transfer Tune 


4ls 


39 s 


38 s 


Transfer Rate 


8.8 KB/s 


92 KB/s 


9.5 KB/s 


Data Transferred 


360 KB 


360 KB 


360 KB 


Buffer Size 


100 KB 


100 KB 


100 KB 


Average Packet Size 


1362 bytes 


1 388 bytes 


136 J bytes 


Average Delay 


23 ms 


26 ms 


26 ms 



Table 6: Pump, covert channel attack present 

In Table 6 we show what happens when the number of 
packets in the moving average is increased. Contrary to 
what we expected, this slightly improved the performance. 
A wider moving average takes longer to slow down the con- 
nection, i.e. the value of the moving average never reaches 
the highs that it did with a shorter moving average. This 
behavior is particularly pronounced at the very beginning of 
a connection and exists only until enough packets have gone 
through the gateway to construct a complete moving aver- 
age. In other words, this is only noticeable if the size of the 
moving average is comparable to the amount of data trans- 
ferred through the gateway. When more data is transferred, 
the phenomenon disappears. 



Buffer Size 


100 KB 


200 KB 


300 KB 


Transfer Tune 


41s 


37 s 


35 s 


Transfer Rate 


8.8 KB/s 


9.7 KB/s 


10.3 KB/s 


Data Transferred 


360 KB 


360 KB 


360 KB 


Moving Average 


60 packets 


60 packets 


60 packets 


Average Packet Size 


1362 bytes 


] 375 bytes 


1368 bytes 


Average Delay 


23 ms 


14 ms 


6 ms 



Table 7: Pump, covert channel attack present 

Table 7 shows the behavior of the Pump when the buffer 
size is changed. As expected, the throughput of the pro- 
tocol increases with the increase in buffer space, primarily 
because our implementation allows Low to send data while 
the Pump establishes communication with High. The more 
data that can be sent through during that time, the belter 
the performance. Again, this effect is noticeable only when 
the size of the buffer is comparable to the amount of data 
that goes through the gateway for any particular connection. 
Thus this table, as well as the previous one, mostly deals 
with startup behavior of the protocol. 

5 The Upwards Channel (One- Way For- 
warder) 

The Upwards Channel protocol is a protocol that elimi- 
nates all covert channels by sacrificing some reliability. This 
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protocol is similar to "blind write-up," except here the use 
of a buffer and preset rate control mechanisms provide some 
assurance of delivery. It was first published by David Gold- 
schlag [13]; a similar protocol was implemented by Andy 
Bavier under the direction of Sean O'Malley at the Univer- 
sity of Arizona prior to the publication of [ 13]. This protocol 
is also similar to the Big Buffer scheme of [14] except in 
this case it does not require any trusted components. 




Upwards Channel 



Low Side 
Router 



L. 



Optical 
Link 





Figure &: Upwards Channel 

To eliminate all covert channels, we physically isolate the 
high and low network and put a special gateway in between. 
This gateway comes in two parts: one machine is on the low 
network and the other machine is on the high network. TTiey 
are connected by an optical link, which is a commercially 
available fiber-optic based device in which data can only 
flow in one direction (Fig. 8). 

When the low side of the gateway receives a message 
from. Low, it simply forwards it on to the high side via the 
optical link and acknowledges receipt of the packet. The 
high side of the gateway places the message into a buffer 
and forwards messages from that buffer to High. 

The obvious problem with this protocol is that if a mes- 
sage gets corrupted or the buffer becomes full, some data will 
be lost with no possibility of automatic recovery. However, 
this may be acceptable if the high receiver is sufficiently re- 
liable and fast enough to prevent the gateway 's buffer from 
filling up. 

5.1 Downgraders 

Goldschlag further proposed to improve the protocol 
by providing some downward flow of information through 
downgraders. A downgrader is a trusted device that is lo- 
cated between the high and low sides of the gateway and 
provides the only flow of information from High to Low 
(Fig. 9). 




Figure 9: Upwards Channel with a Downgrader 

One proposed flavor of downgrader, called a "capacitor," 
works as follows: every time the low side of the gateway 
sends a packet to the high side, it signals the capacitor. When 
the high side receives an acknowledgment for that packet, 
it also signals the capacitor. At the end of a predefined time 
period the capacitor will signal the low side that the packet 
has been received by High. If the packet has not been ac- 
knowledged by the end of the predefined time period, the 
capacitor will shut down all communication and a manual 
reset will be required. This allows Low to request infor- 
mation from High at a predefined rate in such a way that 
it does not carry any timing information (or rather almost 
no timing information — a lack of a signal certainly does 
carry a small amount of timing information, although it also 
causes an immediate termination of operation). 

Another flavor of downgrader proposed by Goldschlag 
can provide some flow control. This downgrader works just 
like a capacitor but it also provides flow control by delaying 
the signal to the low side of the gateway by the moving 
average of the last m acknowledgment times from High 
instead of signaling at the end of a predefined time period. 
Again, if the packet has not been acknowledged by the end 
of the predefined time period, the capacitor will shut down 
all communication and a manual resetting will be required. 

Both of these schemes of downgraders work reasonably 
well if the communication is maintained within a certain 
predefined bandwidth. Outside of this bandwidth commu- 
nication is not possible. 

5.2 Implementation 

The Upwards Channel was implemented as two proto- 
cols: the high gateway protocol and a low gateway protocol, 
both above TCP. The communication over a one way link 
was accomplished using the UDP protocol. A virtual pro- 
tocol called "RC" or "Rate Control" protocol was inserted 
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between the low gateway Upwards Channel and UDP in 
order the keep the rate of messages within the capacity of 
the optical link. Fig. 10 illustrates this configuration. 



process, and a buffer in between.(Fig. 11) 



Upwards. 



7H 



RC 



UpwanU_r 



1^- 



UDP 



TCP 



Eth ! 

1 


FDD1 


[£r | h>di 

1 




Eth 


1 
1 












Low Security Network j 

i 


1 High Security Network 





Figure 10: Upwards Channel protocol configuration 

The TCP and IP protocols were modified as with SAFP 
and the Pump in order to provide similar services. 

5.3 Experimental Results 

Our experiments confirmed that the Upwards Channel is 
a viable protocol that meets its design goals. We weren't 
able to derive any concrete performance measurements of a 
real setup due to the lack of necessary hardware (one-way 
optical link, etc.). Our simulations on a Sun SPARC showed 
sustained data rates comparable to those of SAFP and the 
Pump. 

6 The Quantized Pump 

Hie Quantized Pump protocol proposed here is a hybrid 
between the Pump and the downgrades. Its design goals 
are: to make it easily analyzable and easily controllable 
without sacrificing any performance. Having a provable 
bound on the sire of a covert channel is a priority in the 
design of any secure system. Here we present three versions 
of the Quantized Pump: the straightforward version, the 
logarithmic, and the linear Quantized Pumps. The latter 
versions have certain performance advantages/tradeoffs. 

The idea is to achieve an absolute bound on covert chan- 
nel bandwidth by letting the trusted high process send ex- 
actly so many bits per second to the trusted low process. If 
there is no other information flowing from the high trusted 
process to the low trusted process, then there will be no other 
information flowing from the high security network to the 
low security network. The crux of the algorithm is then find- 
ing the best use for the bits that are allowed to flow between 
the high trusted process and the low trusted process. 

On the surface, the Quantized Pump looks just like a 
regular Pump: it has a low trusted process, a high trusted 




Figure 11: Quantized Pump 

There are two important differences from the Pump: 
buffer size and communication between the high trusted 
process and the low trusted process. The buffer does not 
have a fixed size. 3 This is important because it allows us to 
completely isolate the low trusted process from the buffer. 
Such isolation prevents a possible covert channel where both 
the high and the low trusted process are competing for access 
to the buffer, which may be measurable from the outside of 
the gateway. In the regular Pump, the trusted low process 
has to have more access to the buffer to make sure that it 
doesn't overflow; also, one possible implementation of the 
Pump involves having the trusted low process measure how 
often the trusted high process takes the data out of the buffer 
in order to compute the value of the moving average. 

But the main difference is that the trusted high process 
communicates with the trusted low process in a very re- 
stricted way: at the end of every predefined lime period T % 
the trusted high process sends exactly one bit to the low 
trusted process. That bit carries the following meaning: ei- 
ther raise the rate of acknowledgments to Low by a fixed 
constant rate R bytes/second or lower the rate of acknowl- 
edgments by R bytes/second. 

How does the trusted high process decide whether to 
raise or lower the rate of acknowledgments? The trusted 
high process keeps track of the number of bytes that High 
acknowledged during this time period. By dividing this 
number by T, the trusted high process gets the current aver- 
age rate in bytes/second. If this average rate is greater than 
the current rate that the low trusted process uses (remember 
the high trusted process is allowed to get data from the low 
trusted process; it is the other direction that is restricted), 
then the high trusted process will signal the low trusted pro- 
cess to raise the rate of acknowledgments by R. Otherwise, 
it will signal the low trusted process to lower the rate of 



3 We will show later that despite this characteristic, there is a maximum 
size that the buffer will never exceed. 
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The Fig. 12 and 13 illustrate the difference between 
the Pump and the Quantized Pump acknowledgment rates. 
Fig. 12 shows the delays generated by the moving average 
construction of the Pump. 
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Figure 13: Quantized Pump delays 

Fig. 13 shows how the Quantized Pump constructs the 
delays. There are distinct levels present in this illustration. 
The vertical distance between each two adjacent levels is R 
and the jump from one level to the next happened every T 
seconds. 

The protocol is called "Quantized Pump" because com- 
munication between the trusted high process and the trusted 
low process happens on a once-per-time-interval basis — 
quantum, hence the name — Quantized Pump. 

6. 1 Covert Channel 

The number of bytes acknowledged per unit time is en- 
tirely within High's control, therefore High can directly af- 
fect what the high trusted process will send to the low trusted 
process inside the Quantized Pump. In other words, we have 
a covert channel. Fortunately, from the way we setup this 
protocol we know exactly what the bandwidth of that covert 



channel is, since we have exactly one bit passed from the 
trusted high process to the trusted low process every T sec- 
onds, i.e. the bandwidth of the channel is exactly 
bits/second. 4 

62 Maximum Buffer Size 

Previously we said that the size of the buffer is not fixed. 
Despite the absence of any explicit restrictions on the buffer 
size, the size of the buffer is nonetheless strictly bounded. 

Let Z/ maar be the maximum rate (in bytes/second) at which 
Low can send information to High via the Quantized Pump. 
The largest amount of buffer space is needed when Low 
starts out at the rate of L max and High refuses to accept 
anything. Clearly, at least this much buffer space might be 
needed, since this a possible situation. 

To show that this is also the largest amount of buffer 
space that will ever be needed, we make the following ob- 
servation: if High lowers the rate of acknowledgments by 
some amount and then raises the rate of acknowledgments 
by that same amount, then the occupied buffer space will 
not change. Here is the proof: let L be the initial rate of in- 
formation mat Low is sending and let H be the initial rate of 
acknowledgments from High. The amount of buffer space 
needed for the first time interval is: {L - H)T. Suppose 
High lowers the rate of acknowledgments by iR % where i is 
some integer constant. Then the total amount of buffer space 
needed before the Low and High rates will be balanced out 
is: {L-H)T+(L-R- H)T + (L - 2R - H)T + ... + 
(L - iR - H)T. This can be rewritten as: 



r^(L-jJ?-/f) = (t + l)(L. 



1 



iR~H)T (I) 



If High now raises the rate of acknowledgments by iR, 
then the amount of buffer space that will free up in the first 
time interval is: (H + iR - L)T and the total amount of 
buffer space that will free up before the Low and High rates 
will be balanced out is: 



• i 

tY,(h + iR -£) = (« + + » iR - L ) T 



(2) 



j=0 



Expressions (1) and (2) are equal and opposite in value, 
which means that if High lowers the rate of acknowledg- 
ments by some amount and then raises it by the same amount, 
the used space in the buffer will not change. The same argu- 
ment holds true in the other direction, i.e. if High raises the 



4 This is only strictly tnic if we assume that other factors such as time 
sharing of the same processor, huffer sharing, device sharing, etc. between 
the trusted high process and the trusted low process do not introduce any 
further covert channels. Real-time operating systems can significantly help 
with these issues. 
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rate of acknowledgments by some amount and then lowers 
it by the same amount, the used space in the buffer will not 
change. 

Now we are back to our original argument that the largest 
amount of buffer space ever needed is when Low starts out 
at the rate of Lmax and High refuses to accept anything. 
High cannot lower the rate of acknowledgments any further, 
and so the only thing that High can do that will affect the 
size of the buffer is raise the rate of acknowledgments. But 
this will free some space in the buffer. If High subsequently 
lowers the rate of acknowledgments, it will not use up any 
more buffer space than we had originally by the lemma 
above. Therefore, we can conclude that the largest amount 
of buffer space ever needed is when Low starts out at the 
rate of L max and High refuses to accept anything. 

This maximum buffer size now is easy to calculate. It 
is simply: B max = max R)T + (L m ax 

2i*)T4-..-f RT + Q. Or: 

Bmax — —{Lmaxf R + l^max^" 

For ins Lance, if the maximum data rate from Low, L max , 
is ICQ Kbytes/second, J? is 10 Kbytes/second, and the covert 
channel size is 0.1 bits/second, i.e. T is 10 seconds, then 
the buffer space needed is 55 Mbytes. This is the maximum 
buffer space that will possibly be needed. On average, buffer 
space usage will be much smaller. 

63 Logarithmic Quantized Pomp 

The previous example illustrated a buffer size that is 
acceptable in many applications. However, the maximum 
size of the bufler grows quadratically with L maxt i.e. it is 
0{L? ma£ ) , which may be tolerable but not desirable. We can 
improve this behavior without introducing any additional 
covert channel bandwidth by using a cleverer encoding in 
communication between the high trusted process and the 
low trusted process. 

The Logarithmic Quantized Pump works exactly like the 
Quantized Pump, except the single bit that is passed from the 
trusted high process to the trusted low process once every 
T seconds is interpreted differently. The signal to raise the 
rate can be treated just as before, since it does not increase 
the buffer space used. 

The signal to lower the rate is now interpreted differently: 
if the immediately prior signal from the high trusted process 
was to raise the rate of acknowledgments, then the low 
trusted process will now lower the rate by R\ if the prior 
signal from the high trusted process was to lower the rate of 
acknowledgments, then the trusted low process will lower 
the rate by twice the amount it was lowered previously. 
For instance, the sequence of six bits: "raise, lower, lower, 
lower, raise, raise" will result in the following adjustments to 



the acknowledgment rate by the trusted low process: "raise 
the rate by R, lower the rate by R, lower the rate by 2fl, 
lower the rate by AR, raise the rate by R, raise the rate by 

Rr 

This seemingly trivial change allows us to lower the rate 
from L m ax to zero in only \og 7 (L max /R) steps instead 
of {Lmax/R) steps as before, saving buffer space. The 
complete expression for maximum buffer size now looks 
like this: B max = L max T+(L max -R)T + {L max -R- 
2R)T+{L max -R-2R-4R)T + ... + 0. Or 

fp i 
t=0 j=0 

where rj> is the number of steps necessary to get from L max 
down to zero. This expression has a closed form: 

B m ax = T(L max + 1>{L max + R)~ 2R(2+ - 1)) 

To the first approximation, V> = log 2 (L maJ ?/^) and so 
the expression turns into: 5 

£ m „=T((logL mM -log R){L max 

+ 2R) 

The buffer size now grows as 0(L max log L max ) instead 
of 0(L max ), with no increase in covert channel bandwidth. 
The throughput is slightly reduced (10% or less); see section 
6.7 for exact performance numbers. 

6.4 Linear Quantized Pump 

The Logarithmic Quantized Pump buffer space advan- 
tage over the regular Pump derives from converting band- 
width into less buffer space. In this section we demonstrate 
two possible ways to save more buffer space at the expense 
of sacrificing additional bandwidth, without introducing any 
extra covert channel capacity. 

The Linear Quantized Pump works in the same way as 
the regular Quantized Pump, but the bit passed from the 
high trusted process to the low trusted process once every 
T seconds is treated differently. The signal to raise the rate 
of acknowledgments is treated the same way, i.e. the low 
trusted process will raise the rate of acknowledgments by 
a predefined constant R. The signal to lower the rate of 
acknowledgments is treated differently. If the high trusted 
process signals the low trusted process to lower the rate of 
acknowledgments, then the low trusted process will lower 
the rate of acknowledgments to zero. The data rate will go 
down to zero and no data will be accepted from Low for that 

5 Wc say "to the first approximation" because the expression is actually 
i* = log 2 {{Lmax I R) + 1) and is exact only if L = R or L - 3R 
or L = 7R or in general if L — (2* - l)R\ if L does not have such a 
convenient form, the last term of the summation will not be complete and 
some approximation will be necessary. 
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quantum period T. Subsequent signal from the high trusted 
process to raise the data rate will raise it from zero to R, 
then to 2K, then to 3R and so on. 

The decision of whether to raise or lower the rate of 
acknowledgments is made by the high trusted process in ex- 
actly the same way as in the regular Quantized Pump. The 
trusted high process keeps track of the number of bytes that 
High acknowledged during this time period. Dividing this 
number by T, the trusted high process gets the current aver- 
age rate in bytes/second. If this average rate is greater than 
the current rate that the low trusted process uses, then the 
high trusted process will signal the low trusted process to 
raise the rate of acknowledgments by R. Otherwise, it will 
signal the low trusted process to lower the rate of acknowl- 
edgments to zero for the duration of the next quantum. 

The bandwidth of the covert channel is again 1/T 
bits/second because the only communication between the 
high trusted process and the low trusted process is a single 
bit every T seconds, but the amount of buffer space needed 
is now substantially less. 

The maximum buffer space needed is when Low starts 
out at the rate of L maj! and High refuses to accept anything. 
It takes exactly one quantum time period T to equalize these 
two rates. This means that the maximum total buffer space 
needed is only: 

-BfTicx = TL m ax 

In other words, the Linear Quantized Pump has the space 
complexity of 0{L max ) as compared toO(£nuir logI max ) 
for the Logarithmic Quantized Pump and for the 

regular Quantized Pump. 

This improvement in buffer size comes at a price: the 
loss of available bandwidth. If we analyze the behavior of 
the Linear Quantized Pump, we find that it is similar to the 
behavior of TCP Reno (the standard implementation of TCP) 
in that from time to time it sharply drops the data rate and 
then linearly climbs back to its previous value, exceeds it, 
drops again, and climbs back again. (The difference is that 
in Reno the data rate drops by half and in Linear Quantized 
Pump we drop it all the way down to zero.) In other words, 
Linear Quantized Pump spends most of its time climbing 
from the data rate of zero bytes/second to the actual best 
available data rate. The average data rate is approximately 
half of the available bandwidth. The experimental results in 
section 6.7 confirm this. 

It is possible to have the Quantized Pump behave like 
TCP Reno (reduce the data rate by half as opposed to 
reducing it to zero). It will have a 50% better average 
throughput than the Linear Quantized Pump while hav- 
ing approximately the same average buffer usage. In the 
worst case scenario, 'TCP Reno-like" Quantized Pump has 
double the space usage of the Linear Quantized Pump, i.e. 
Bmax = 2TL max , instead of B max = TL max , 



6.5 Possible Further Improvements 

We can reduce the covert channel bandwidth further by 
introducing random noise into the bits controlling the ac- 
knowledgment rate. (This works best with the original ver- 
sion of the Quantized Pump.) For instance, with 20% noise 
(i.e. on average, one of every five bits is randomly flipped), 
we get a reduction in the covert channel bandwidth by nearly 
73%. The usefulness of this measure is doubtful, since the 
covert channel bandwidth can be set by simply changing the 
constant T. 

Another possible improvement is to have a single gate- 
way incorporate all three versions of the Quantized Pump 
presented in the previous sections. Since the regular Quan- 
tized Pump offers the best data throughput but is the least 
efficient in terms of buffer space, we start communication 
using the regular Quantized Pump protocol. If the buffer 
space starts running short, the gateway would switch to Log- 
arithmic Quantized Pump protocol, which is better in buffer 
space management but offers slightly inferior data rates. If 
the buffer space becomes critical, the gateway might switch 
into Linear Quantized Pump mode, where the least amount 
of buffer space is required, but the data throughput would 
also suffer a substantial drop. 

Tnese switches between different protocols can be ac- 
complished by the low trusted process without any addi- 
tional information from the high trusted process, and thus 
it would not introduce any additional information flowing 
from High to Low. This implies that such an adaptive gate- 
way would not add any bandwidth to the covert channel 
from High to Low. Notice that the algorithm for the trusted 
high process is identical for all three versions of the Quan- 
tized Pump. The high trusted process does not need to be 
notified of protocol change — the low trusted process can 
change its algorithm on its own. 

The algorithm for switching between protocols cannot 
be exact, since the low trusted process does not have direct 
access to the available buffer space (which might introduce 
an additional covert channel). The switching between pro- 
tocols can still be accomplished by using a heuristic: if the 
high trusted process has been trying to lower the data rate 
for the last several turns, then the buffer must be starting to 
fill up and it is time for a more space-efficient protocol. If 
the high trusted process has been trying to raise the data rate 
for the last several turns, then the buffer must be emptying 
out and it is time to switch to a faster protocol. 

6.6 Implementation 

The Quantized Pump is implemented in a way very sim- 
ilar to the regular Pump. The trusted high process and the 
trusted low process are threads within the same protocol 
process. The communication between the trusted high pro- 
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cess (thread) and the trusted low process is accomplished by 
means of a one bit shared variable that is updated once per 
time interval T. The protocol graph looks exactly like the 
protocol graph of the Pump; see Fig. 7 for details. 

The buffer was isolated from the trusted low and high 
processes, with only the "put" operation available to the 
low trusted process and only the "get" operation available 
to the high trusted process. Both TCP and IP protocols were 
modified as for the regular Pump. 

6.7 Experimental Results 

Tables 7 t 8, and 9 summarize behavior of our imple- 
mentation of the Quantized Pump with various parameters 
changing. In all three cases there is a covert channel present. 
As with SAFP and the Pump, 1 was encoded with a 250 mil- 
lisecond delay and 0 with no delay. 

The parameters for the Pump and the Quantized Pump 
were chosen to roughly approximate each other: 20 ms/byte 
for the l/R parameter for the Quantized Pump and a 60 
packet moving average for the Pump. These parameters 
lead to roughly similar times for a data change rate from 
Cms delay to 250 ms delay of the covert channel and thus 
allow a fairer comparison of the protocols. 



Data Transferred 


360 KB 


720 KB 


1.4 MB 


Transfer Time 


37 s 


77 s 


170 s 


Transfer Rate 


9 J KB/s 


9.4 KB/s 


8.2 KB/s 


Quantum (T) 


Is 


1 s 


1 5 


Rate of change (1/R) 


20 ms 


20 ms 


20 ms 


Average Packet Size 


1380byies 


1376 bytes 


1361 bytes 


Average Delay 


23 ms 


29 ms 


29 ms 



Table 8: Quantized Pump, covert channel present 



Comparing Table 8 to Table 5 and Table 2, we see that the 
Quantized Pump protocol performed slightly better than the 
regular Pump and slightly worse than SAFP with the same 
covert channel. This is not a tremendously surprising result, 
since SAFP attempts no substantial covert channel elimi- 
nation and the Pump spends extra time traveling between 
quantized levels of delays of the Quantized Pump. 



Quantum (T) 


Is 


2s 


4s 


Transfer Time 


37 s 


39 s 


40 s 


Transfer Rate 


9.7 KB/s 


9.2 KB/s 


9.0 KB/s 


Data Transferred 


360 KB 


360 KB 


360 KB 


Rate of change (1/R) 


20 ms 


20 ms 


20 ms 


Average Packet Size 


1380 bytes 


1398 bytes 


1362 bytes 


Average Delay 


23 ms 


29 ms 


25 ms 



Table 9: Quantized Pump, covert channel present 



Table 9 shows what happens to the performance of the 
Quantized Pump as the bandwidth of the maximum covert 
channel was decreased from 1 bit/second to 0.25 bits/second. 



As expected, the throughput was reduced because the Quan- 
tized Pump now required more time to adjust. With the 
covert channel bandwidth limited to 0.25 bits/second, the 
throughput of the Quantized Pump is still slightly better 
than that of the regular Pump in Table 5, first column. 



Rate of change (1/R) 


20 ms 


40 ms 


80 ms 


Transfer Time 


37 s 


38 s 


37 s 


Transfer Rate 


9.7 KB/s 


9.5 KB/s 


9.7 KB/s 


Data Transferred 


360 KB 


360 KB 


360 KB 


Quantum (T) 


Is 


Is 


t s 


Average Packet Size 


1380 bytes 


1426 bytes 


1406 bytes 


Average Delay 


23 ms 


23 ms 


22 ms 



Table 10: Quantized Pump, covert channel present 



The effects of changing the parameter R are illustrated 
in Table 10. Changes in R do not have much effect on the 
throughput of the Quantized Pump. 



Data Transferred 


360 KB 


720 KB 


1.4 MB 


Transfer Time 


42 s 


80s 


166s 


Transfer Rate 


8.6 KB/s 


9.0 KB/s 


8.4 KB/s 


Quantum (T) 


1 s 


Is 


Is 


Rate of change (1/R) 


20 ms. 


20 ms 


20 ms 


Average Packet Size 


1289 bytes 


1343 bytes 


1357 bytes 


Average Delay 


18ms 


23 ms 


27 ms 



Table 11: Log. Quantized Pump, covert channel 



Table 11 illustrates the performance of Logarithmic 
Quantized Pump. Trie throughput is approximately 12% 
worse than the Quantized Pump for a small data transfer 
but only 3% worse than the Quantized Pump for a much 
larger data transfer. For even larger data transfers, the dif- 
ference becomes even less pronounced. The logarithmic 
behavior in buffer growth completely justifies this slightly 
lower performance of the Logarithmic Quantized Pump. 



Data Transferred 


360 KB 


720 KB 


^ 1.4 MB 


Transfer Time 


85 s 


179s 


386 s 


Transfer Rate 


4.2 KB/s 


4.0 KB/s 


3.6 KB/s 


Quantum (T) 


i s 


1 s 


1 s 


Rate of change (1/R) 


-1 s/+20 ms 


-1 S/+20 ms 


-I s/+20ms 


Average Packet Size 


1292 bytes 


1333 bytes 


1 299 bytes 


Average Delay 


13ms 


19 ms 


22 ms 



Table 12: Linear Quantized Pump, covert channel 



Finally, Table 12 shows the performance numbers for the 
Linear Quantized Pump. As advertised in the previous sec- 
tions, the Linear Quantized Pump sacrificed about half the 
bandwidth to eliminate all but a small size buffer. The table 
shows rate of change parameter 1/R as: - 1 000ms/+20ms, 
-1000ms is the duration of the quantum (T), thus for that 
quantum there was no data transmitted and the data rate is 
zero. 
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7 Conclusion 

We examined several previously proposed protocols that 
aim at reducing the bandwidth of covert channels. We dis- 
cussed our implementations of these protocols and some 
practical problems that come up when implementing these 
protocols. 

We introduced a new protocol, the Quantized Pump, 
which is easy to configure, easy to analyze, has a prov- 
able upper bound on the covert channel bandwidth, and 
has better performance characteristics than the Pump. We 
demonstrated several different versions of the Quantized 
Pump with different data-rate/buffer-size tradeoffs. 

Finally, we supported our claims with comparative per- 
formance numbers for all of the protocols discussed. 
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